Skip to content

Add a section to the PR guide on how to write good titles and descriptions#1845

Open
sirosen wants to merge 3 commits into
python:mainfrom
sirosen:add-pr-title-and-desc-guidance
Open

Add a section to the PR guide on how to write good titles and descriptions#1845
sirosen wants to merge 3 commits into
python:mainfrom
sirosen:add-pr-title-and-desc-guidance

Conversation

@sirosen

@sirosen sirosen commented Jun 26, 2026

Copy link
Copy Markdown
Contributor

Add a short section to the PR guide which covers good titles and descriptions, at a summary level.

The priority here is (in presentation order):

  • explain the rationale / why we care
  • demonstrate how a PR title should look
  • give some hint as to what a good description will look like

Explaining how to write good technical prose for a PR description is considered out of scope, which limits the content of the PR description section.


Resolves #931
Supersedes prior PRs, and therefore

Add a short section to the PR guide which covers good titles and
descriptions, at a summary level.

The priority here is (in presentation order):
- explain the rationale / why we care
- demonstrate how a PR title should look
- give some hint as to what a good description will look like

Explaining how to write good technical prose for a PR description is
considered out of scope, which limits the content of the PR description
section.
@read-the-docs-community

read-the-docs-community Bot commented Jun 26, 2026

Copy link
Copy Markdown

Documentation build overview

📚 CPython devguide | 🛠️ Build #33331823 | 📁 Comparing cc60068 against latest (0164145)

  🔍 Preview build  

3 files changed
± getting-started/index.html
± versions/index.html
± getting-started/pull-request-lifecycle/index.html

Comment thread getting-started/pull-request-lifecycle.rst Outdated
The title should be a sentence or phrase in the imperative which says what the
pull request does in short form. It should start with ``gh-NNNNNN:``, for pull
requests which close open issues.
For example, ``gh-12345: Fix bug when spam module is served with eggs``.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some of this is duplicated in the Submitting section. To me, the Making good PRs section seems like a checklist about the change itself, not a checklist for the PR on GitHub.

I think, looking at the (albeit quite terrible) flow, this section is too early (the following section here is about pre-submission things, for example), and can be merged with the duplicated content in Submitting.

@sirosen sirosen Jun 27, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can see what you're getting at. I think I'd like to make further changes to "Submitting" -- I don't think it's quite right in scope right now -- but not right now.

I'd like to move this section down and deduplicate a bit. I'll try to be surgical in my changes, but avoiding repetition strikes me as a good reason to increase the scope of my changes.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I moved it and think the result is "okay".

To make it really great we'll need to make more changes than I can reasonably fit in here. 🙂

sirosen and others added 2 commits June 26, 2026 18:49
Give this section a referenceable label, and place it in the
"Submitting" section rather than "Writing good pull requests".

Keep the content largely the same, but add a new trailing sentence to
note that `#NNNNN` syntax can link issues. This replaces a note from
"Submitting" that was mostly redundant with the new section.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Improve the "Making Good PRs" section

2 participants